Netlify deploy preview

https://deploy-preview-40425--material-ui.netlify.app/

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against 8ea34d2

Even the inputRef isn't documented for NumberInput. Do you think it should be available on NumberInput? I believe it should.

I don't think inputRef is a valid prop. if you check below sandbox line 16,17, only line 17 logs input element as it is passed through slotProps.input where as line 16 doesn't. as it was passed through inputRef.

https://codesandbox.io/p/sandbox/funny-knuth-kc8h4d?file=%2Fsrc%2FDemo.tsx%3A17%2C17-17%2C29

So i think inputRef should be removed from NumberInput Type. Removed in 8ea34d2

Even the inputRef isn't documented for NumberInput. Do you think it should be available on NumberInput? I believe it should.

I don't think inputRef is a valid prop. if you check below sandbox line 16,17, only line 17 logs input element as it is passed through slotProps.input where as line 16 doesn't. as it was passed through inputRef.

https://codesandbox.io/p/sandbox/funny-knuth-kc8h4d?file=%2Fsrc%2FDemo.tsx%3A17%2C17-17%2C29

So i think inputRef should be removed from NumberInput Type. Removed in 8ea34d2

It's currently not available, but shouldn't we support it by adding the implementation? Although it's supported in slotProps.input, we can make it a direct prop on NumberInput and pass it to the useNumberInput hook. Currently, it's only available on useNumberInput.

As for inputId, the id prop of NumberInput was considered as inputId, so it's correct that it shouldn't be available for NumberInput. However, for user clarity, it might be better to explicitly use inputId in NumberInput for input and id for root.

In essence, all the props for useNumberInput should be available on NumberInput since the hook is used to build the NumberInput component internally.

If you agree, these changes can be done in a separate PR. If implemented in a separate PR, we would need to revert 8ea34d2 here. Alternatively, you can include all these changes in this PR, altering its purpose altogether.

I agree with you on providing inputId and id, but if you look at https://mui.com/base-ui/react-input/components-api/. Even Input component doesn't have explicit inputId and inputRef ( even though hook version of input accepts inputRef) . So maybe it was conscious choice for not allowing inputRef, inputId on Input and NumberInput components.

In essence, all the props for useNumberInput should be available on NumberInput since the hook is used to build the NumberInput component internally.

I'm not sure if above hypothesis is true, because if check https://mui.com/base-ui/react-button/hooks-api/ and https://mui.com/base-ui/react-button/components-api/ props, there are multiple props which are not common in component version and hook version. Also Difference in props across hook and component versions is not just limited to Button component, many components have it

I agree with you on providing inputId and id, but if you look at https://mui.com/base-ui/react-input/components-api/. Even Input component doesn't have explicit inputId and inputRef ( even though hook version of input accepts inputRef) . So maybe it was conscious choice for not allowing inputRef, inputId on Input and NumberInput components.

In essence, all the props for useNumberInput should be available on NumberInput since the hook is used to build the NumberInput component internally.

I'm not sure if above hypothesis is true, because if check https://mui.com/base-ui/react-button/hooks-api/ and https://mui.com/base-ui/react-button/components-api/ props, there are multiple props which are not common in component version and hook version. Also Difference in props across hook and component versions is not just limited to Button component, many components have it

Alright, I see. Then this PR looks good.